Description of the DES-Tracker v1.0 file format ("DTL0") ======================================================== As of Dec 18, 1993 Written by Darren Schebek Copyright ©1993 by Darren Schebek All rights reserved This text file contains a description of the DES-Tracker v1.0 song module file format, henceforth referred to as the "DTL0" format. For those familiar with various module file formats, the "DTL0" file format is most closely related to the Soundtracker v2.6 file format. As such, this is not an IFF format. Rather, it's just another file format thrown on the heap. However, it's more efficient and flexible than the Soundtracker v2.6 format (which is already *way* more efficient than the Noisetracker/ Protracker file format), resulting in smaller module files. There are a few features worth noting about the "DTL0" file format. First, like with Soundtracker, patterns are 256 bytes long. A "pattern" in this context is an array of 64 longword note events to be played by a single audio channel. The "DTL0" format can handle up to 65,535 patterns in a single song file. Soundtracker v2.6 can only handle up to 255. As a result of the above feature, the pattern sequence table requires 4-word elements (instead of 4-byte, like Soundtracker v2.6) in order to specify pattern numbers greater than 255. The "DTL0" file format is smart, in that it will store 4-byte elements in the pattern sequence array if the number of unique patterns is less than or equal to 256. If the number of unique patterns is greater than 256, then 4-word elements are stored. Also, the pattern sequence array has only as many elements as there are positions in the song. If a song has 18 positions, then the array will be 18 elements long in the file. Soundtracker v2.6 always contains an array of 128 4-byte elements regardless of how many elements are actually used. Lastly, extra fields have been added to indicate intial timing conditions for the song. One or two of these fields are rather specific to DES-Tracker, but they may still be of use to others nonetheless. Here is a byte-by-byte description of the file: File Field Offset Size Description 0 4 Four-byte ID code: "DTL0" indicating that this is a "DTL0" file format. 4 20 The title of the song, padded with NULL's. 24 930 Instrument info blocks. There are 31 of them, and each one is 30 bytes in length. An instrument info block looks like this: 22 bytes Instrument's name. 2 bytes Length of instrument sample in words. 1 byte Its fine tune value (-8..+7). 1 byte Its default volume (0..64). 2 bytes Its repeat offset in words. 2 bytes Its repeat loop length in words. An instrument info block with a length field that contains 0 is to be considered an "empty slot" (i.e., No instrument sample is associated with this instrument info block). 954 1 Playback flags. There are currently two of them: Bit 0: Timing mode for playback. 0 = 60Hz playback. 1 = 50Hz playback. Bit 1: Tempo interpretation. If this bit is 0, then SETTEMPO (command $F) operands are to be considered as such: 0..31 = Normal tempo operands. 32..255 = BPM tempo operands. If this bit is set to 1, then the entire range (1..255) of the SETTEMPO operand field is to be considered a normal tempo operand (i.e., No BPM tempos). 955 1 Default (initial) tempo for playback (0..255). 956 1 Fine tempo for playback. This is a value in the range -128..127. It represents a fine adjustment to the overall tempo of the song in units of 0.078125Hz. So, a value of 127 increases the overall tempo of the song by +10Hz, whereas a value of -128 decreases the overall tempo by -10Hz. 957 1 Default number of iterations (0..255). A value of 0 here means that the song is meant to loop forever. 1 means play the song once and then stop, 2 means play it twice, etc. 958 2 The number of positions in the song (referenced in this document as nPos). This is a value that should never be higher than 128. It is a word for the sake of future consideration. If this file format HAS a future, I should say. :) 960 2 The number of unique patterns in the song (referenced here with nPatt). Patterns are 256 bytes long, containing 64 longword note events for a single audio channel. 962 nPos * ( (nPatt > 256) ? 4 : 8) The pattern sequence array. Each element in the array contains four pattern numbers - one for each audio channel that are to be played simultaneously. If the number of patterns is 256 or less then the pattern numbers will be byte values (4-byte array elements). If the number of patterns is greater than 256 then the pattern numbers will be word values (4-word array elements). Varies nPatt * 256 The pattern data. There are nPatt patterns here. Each one is 256 bytes in length. Protracker effects and "E" commands are allowed. Varies Varies The instrument sample data appears here, immediately after the last pattern. Sample data appears in the same order as the corresponding instrument info block (described previously). There is no sample data for "empty slots" (i.e., instrument info blocks with a length field containing 0). EOF That's about all there is to it. I would probably not have designed the "DTL0" file format had I not actually come across a song module that had over 256 unique patterns when converted from Protracker to Soundtracker v2.6. This made me realize that such a thing is possible, and as I detest the inefficiency of the Noisetracker/Protracker file format, I felt I should come up with a variation of Soundtracker v2.6 that could handle more unique patterns. Nobody is obligated to use this format and in all truth, perhaps nobody really should use it. However, it's perfectly safe to use, as DES-Tracker can easily convert back and forth between DTL0 and NoiseTracker/ Protracker. Note that I decided to retain the storage of "empty" instrument info blocks to preserve instrument names that have been stomped for the sake of a silly message. This is normally a practice I abhor since it's only going to cause problems in the long run. Really, SampleTexts are a much, much better idea and you can say a lot more with them. They're a far better alternative to stomping instrument names. If you want to stomp instrument names, give them names like "Inst1", "Inst2", etc, or something. Although there's absolutely no point in eradicating instrument names in the first place. - Darren Schebek dschebek@outb.wimsey.bc.ca